home *** CD-ROM | disk | FTP | other *** search
/ InfoMagic Standards 1994 January / InfoMagic Standards - January 1994.iso / inet / scc / 9222 < prev    next >
Text File  |  1992-08-24  |  14KB  |  248 lines

  1. **************************************************************************
  2. Security Bulletin 9222                  DISA Defense Communications System
  3. August 25, 1992             Published by: DDN Security Coordination Center
  4.                                       (SCC@NIC.DDN.MIL)   1-(800) 365-3642
  5.  
  6.                         DEFENSE  DATA  NETWORK
  7.                           SECURITY  BULLETIN
  8.  
  9.   The DDN SECURITY BULLETIN is distributed by the DDN SCC (Security
  10.   Coordination Center) under DISA contract as a means of communicating
  11.   information on network and host security exposures, fixes, and concerns
  12.   to security and management personnel at DDN facilities.  Back issues may
  13.   be obtained via FTP (or Kermit) from NIC.DDN.MIL [192.112.36.5]
  14.   using login="anonymous" and password="guest".  The bulletin pathname is
  15.   scc/ddn-security-yynn (where "yy" is the year the bulletin is issued
  16.   and "nn" is a bulletin number, e.g. scc/ddn-security-9222).
  17.  
  18. **************************************************************************
  19. + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
  20. !                                                                       !
  21. !     The following message is being relayed unedited via the           !
  22. !     Defense Information Systems Agency's Security Coordination        !
  23. !     Center distribution system as a means of providing DDN            !
  24. !     subscribers with useful security information.                     !
  25. !                                                                       !
  26. + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
  27.  
  28.                             "ALIENS 4": Epilogue
  29.                                  Dave Bouwer
  30.                                   23 Aug 92
  31.  
  32. On August 15, 1992, an alert for what was believed to be a new  
  33. "polymorphic" or "adaptive" virus strain was posted.  This virus was  
  34. detected on a Macintosh IIci running System 7 at the Space Environment  
  35. Laboratory in Boulder, Colorado.  I was the researcher at NOAA/SEL that
  36. originated the alert, and I assume full responsibility for it.
  37.  
  38. To make a long story short, "Aliens 4" is a ghost--that is, it was either  
  39. a legitimate description or a peculiar combination of multiple  
  40. viruses  and system software problems.  In any case, two weeks of 
  41. work have  failed  to reproduce the original virus, and the alert needs 
  42. to be canceled.
  43.  
  44. For interested readers, I'm describing the circumstances that led 
  45. to the alert and giving some of my personal reflections.  I hope to be 
  46. as honest as  possible in this description so that others in a similar 
  47. situation can learn from my experience.  None of the views here 
  48. represent those of NOAA or anyone else.
  49.  
  50. The Space Environment Lab (SEL) is an amalgam of talented physicists,
  51. computer specialists, students, and administrative personnel.  We do
  52. no classified work, but provide important near-real-time forecasts of the
  53. solar-terrestrial environment in addition to performing general research
  54. in solar-terrestrial physics.  A potential "hacker" has no need to raid
  55. our systems:  We are delighted to provide data nearly free of charge!
  56.  
  57. The computer environment at SEL is a complex combination of real-time
  58. systems, super-computer links, high-end workstations, personal computers,
  59. and a strained ethernet network tying everything together. SEL's extremely
  60. capable staff are always trying, like most shops, to catch up on a 
  61. demanding  backlog of new systems, upgrades, bugs, programming, etc. 
  62. We deal with an enormous amount of data: About 5 GB a day come through our
  63. Services division alone.
  64.  
  65. I have been active in the computer sciences for nearly 20 years as a  
  66. developer, systems manager, and high-end user.  While I am a long  
  67. way from "guru" status, I have a long string of experiences and 
  68. considerable education in government, university, and private industry. 
  69. About 50% of my time is devoted to my  research in the time series analysis
  70. of solar variability; the rest is spent in putting  together the latest
  71. in systems for scientific research.
  72.  
  73. In other words, it was not without careful consideration or some  
  74. expertise that I escalated the virus alert to a national level:  the 
  75. consequences of not alerting others seemed VERY serious, and I was 
  76. nearly certain of what I had observed.
  77.  
  78. Generally, at SEL, we have tended to worry little about computer 
  79. security and have implemented only the basic measures, usually as 
  80. an afterthought.  Our priority is to get the job done, and most users 
  81. in the lab manage their own systems both by choice and necessity. 
  82. However, in the last year the MS-DOS systems have seen two infections:
  83. the infamous "Stoned" and "Michelangelo" viruses.  Our concern about data
  84. security is  beginning to increase.  After all, we do work just down
  85. the street from a major university with a large computer science department!
  86.  
  87. The nine Macintosh systems are all less than a year old, and there  
  88. have seldom been any problems (least of all viruses). The "Lab Mac," 
  89. which  was  available in a general computer lab area for visiting staff, 
  90. students, etc., has been one of my responsibilities.  Since I much prefer
  91. doing my papers and  memos on the Mac instead of on my desk-top DECstation,
  92. I frequently used it and kept it working well (I have been using a Mac for
  93. about 5 years altogether, with a long history of VAX/VMS systems and some
  94. Unix).  About once a month, or whenever a peculiar problem would emerge, 
  95. I would run various combinations of our older anti-viral programs over all
  96. the files, and I had never found a problem.  I was over-confident that our
  97. systems were unlikely to be seriously infected.
  98.  
  99. I discovered the virus on Saturday, August 8, 1992, when I noticed a  
  100. MandelZot Fractal application on the Lab Mac.  Obviously, the neophyte
  101. students were doing what every new computer science student seems to do
  102. on a nice graphics system: making pictures for their dorm rooms!  Such
  103. creative endeavors are not to be discouraged: they often generate enthusiasm
  104. and lead to new ideas.  When I clicked on the application to see how they
  105. were doing, the application alerted me to an infection (ALL applications
  106. should do that!).
  107.  
  108. Not too worried and a little amused, I began to check it out.  The  
  109. fractal application was last modified August 17, 1992, at 11:50 PM. 
  110. (somebody was in very late!) Interferon informed me that a "Type 2"
  111. error was found in the System, Finder, MandleZot, Photoshop, Canopener,
  112. Mac Profiler,  Norton, System Sleuth, and Interferon (now that doesn't
  113. exactly instill a secure feeling!).  I was the one running all the
  114. applications, so I figured I had a VERY infected system.  Since it was
  115. a Saturday, and I had a date, I put a notice on all the users' Macs
  116. (I did not know whether the virus had propagated via the network), posted
  117. a Lab-wide  bulletin, and physically disconnected the Ethernet connections
  118. from all the Macs.  I shut down the Pathworks process running on our
  119. Micro VAX/VMS server.
  120.  
  121. Sunday I came in to work on the problem (so much for my day of fly-fishing
  122. my favorite river!). I ran Virus Rx 1.6, and it immediately became infected
  123. (I can't recall all that it found).  Next, I tried Disinfectant 2.4. 
  124. It reported what the Interferon run the day before had reported, identifying
  125. the virus as an nVIR A strain. I decided to wait until Monday to talk to our
  126. local NIST experts (we work in a large facility with an excellent networking
  127. staff).  I began putting together a new Mac we had just received, planning
  128. to use it as a "test" machine.  I also started planning how to campaign for
  129. new Lab computer security measures:  the long-term implications were  
  130. beginning to sink in!
  131.  
  132. I issued a stronger Lab-wide memo telling users they MUST back up their
  133. files NOW.  I disabled all Macs and told users to see me before starting
  134. their systems. As you can imagine, this directive was not received well
  135. the next day.  In my overwhelming fear of lost data, I decided to err on
  136. the side of caution. This was my first mistake: over-reacting and creating
  137. an atmosphere of panic.
  138.  
  139. Monday, amidst countless user problems, I managed to sit down at the
  140. infected machine with the local security guru.  He came armed with the
  141. latest versions of SAM and Norton.  By then, there were dozens of reports
  142. of printers not  working, system crashes, odd screens, and disk drives
  143. not working.  At this point, I was becoming convinced that at least 3 Macs
  144. were infected.  Only the System 6 Mac's seemed problem-free.  I suspected
  145. that our local Ethernet network was carrying the virus somehow. This was
  146. mistake number two: When users panic, every glitch that would normally be
  147. ignored becomes a  symptom of the virus.  I mis-diagnosed the extent of the
  148. problem on the basis of heresy, and not on my own direct experience.
  149.  
  150. Since one of my bosses -- the one who approves all my recommended  
  151. purchases -- was out of town, I broke the rules and had the division 
  152. secretary rush-order $1800 of SAM and Norton software.  Mistake 
  153. number three: potential loss of data in the organization may not be 
  154. grounds for overstepping one's authority.
  155.  
  156. First we ran SAM (version 2.8 or 2.9).  It reported the nVIR A strain as  
  157. the other diagnostic software had on the previous day.  My NIST 
  158. colleague asked if I had another infected system or disk, and I said I 
  159. was sure I did.  Mistake number four: I should have made absolutely certain
  160. I had copies of the suspected virus.  Other people will want to see any
  161. reported virus.
  162.  
  163. We then told SAM to go ahead and eradicate the virus.  It said it had 
  164. done so, without a problem.  We ran SAM again, and here was where all my
  165. alarms went off:  On the second run, all the prior infected files and a
  166. few new ones (the infected Versaterm Client application was the most ominous)
  167. were infected with the MBDF A virus! 
  168.  
  169. We ran SAM again, telling it to fix the files. Again, it said it did so  
  170. without any problems.  Since we were running from write-locked floppies,
  171. the system had to re-boot.  When it came back up, my external LaCie drive
  172. would not mount. The internal hard drive seemed to have no more problems. 
  173. My NIST colleague could only tell me what I already knew: I had a  problem!
  174.  
  175. I consulted with another Mac expert, and he informed me about the new
  176. adaptive or polymorphic viruses. Then an alert user gave me the new IEEE
  177. Spectrum issue on data security (an excellent treatment in my opinion). 
  178. I became convinced I had at least a 50% chance of having a polymorphic
  179. virus, and that's when I notified CERT of the ALIENS 4 virus (I came up
  180. at the last minute with the name: I felt I had to call it something!).
  181. Mistake number five was in jumping to a conclusion too soon.
  182.  
  183. Now it's two weeks later.  Despite seriously overdue projects, I have  
  184. worked entirely on:
  185.  
  186.    (1) Rebuilding the infected system after erasing the drives
  187.        (implementing the new 7.01, Pathworks 1.1, and removing 
  188.        all but the DECnet and FTP network extensions).
  189.  
  190.    (2) Trying to find the infected disk that started it all,
  191.        or at least SOME copy of it.
  192.  
  193.    (3) Defending against management, user, and network criticisms.
  194.  
  195.    (4) Campaigning for new resources for new Lab-wide computer security
  196.        measures.
  197.  
  198. So far I've only successfully completed (1), and I'm giving up on the 
  199. other three tasks.  It's very hard to maintain political and technical  
  200. clout after getting labeled as a "Chicken-Little."  I do know that a  
  201. department in the University has Macs riddled with the nVIR A strain and a
  202. copy of an X-rated script that MIGHT be used as a Trojan horse (I will be
  203. forwarding copies of that virus and the script to Symantec, Apple, and CERT,
  204. but I believe they will see nothing other than a simple nVIR A strain and
  205. a script of poor taste.)  Other than the normal "glitches," there has been
  206. no additional evidence of an infection.
  207.  
  208. To this day I believe the Lab had a new viral strain that posed a serious
  209. risk.  However, I still ask myself whether I either: (a) saved the lab and
  210. others from catastrophic data loss, or (b) thoroughly embarrassed the
  211. Lab and myself.  I'm sure (b) is true, but I guess I'll never know about (a).
  212. I still maintain that the highest priority, when data loss looms and
  213. confusion and fear begin to overwhelm the beleaguered system manager,
  214. is to protect the data.  Yet I should have been more careful in deciding
  215. to escalate the alarm.
  216.  
  217. In conclusion, because I am unable to reproduce the virus, ALIENS 4 is
  218. just a "ghost."  What we all have to ask ourselves is:  Is ALIENS 4 a  
  219. ghost of "Christmas Future?"  If I did observe a polymorphic or adaptive
  220. virus coming in on some innocuous Trojan horse, how could anyone else know
  221. it?  And if the consequences of a false alarm are too severe, who would
  222. risk their career by reporting a "potential threat"?  Finally, how are we
  223. going to defend ourselves against this kind of mutating computer threat (if
  224. it indeed becomes realized) in departments already straining their resources
  225. to the limits?
  226.  
  227. I leave these questions to the readers of this confessional. I've got a 
  228. very serious backlog of work to do.
  229.  
  230.     Sincerely,
  231.  
  232.     Dave Bouwer.
  233.  
  234.  
  235. ****************************************************************************
  236. *                                                                          *
  237. *    The point of contact for MILNET security-related incidents is the     *
  238. *    Security Coordination Center (SCC).                                   *
  239. *                                                                          *
  240. *               E-mail address: SCC@NIC.DDN.MIL                            *
  241. *                                                                          *
  242. *               Telephone: 1-(800)-365-3642                                *
  243. *                                                                          *
  244. *    NIC Help Desk personnel are available from 7:00 a.m.-7:00 p.m. EST,   *
  245. *    Monday through Friday except on federal holidays.                     *
  246. *                                                                          *
  247. ****************************************************************************
  248.